В большой виртуальной инфраструктуре присутствуют сотни хранилищ VMFS, созданных поверх LUN, где лежат виртуальные машины с различным уровнем требуемого сервиса и политик. Проблемы начинаются с того, что система хранения не знает о том, что на ее LUN находятся виртуальные машины. Например, синхронная репликация на уровне массива может делаться только на уровне LUN, хотя с данного тома VMFS требуется реплицировать не все ВМ, которые могут быть с различным уровнем критичности. То же самое касается снапшотов и снапклонов уровня массива...

Одновременно с анонсом новой версии платформы VMware vSphere 5.1 компания VMware объявила об обновлении средства VMware vSphere Storage Appliance 5.1 (VSA), которое позвляет организовать общее отказоустойчивое хранилище для виртуальных машин на базе локальных дисков хост-серверов VMware ESXi с использованием двух или трех узлов. О новых возможностях VSA предыдущей версии (1.0) мы уже писали вот тут, а сегодня расскажем о новых возможностях и лицензировании версии 5.1.

Итак, что нового появилось в VMware vSphere Storage Appliance 5.1:

Максимально поддерживаемые характеристики локальных хранилищ серверов ESXi теперь таковы:

3 ТБ диски

• 8 дисков до 3 ТБ каждый в конфигурации RAID 6 (без hot spare)
• 18 ТБ полезной емкости под тома VMFS-5 на 1 хост
• 27 ТБ полезной емкости на 3 хоста

2 ТБ диски

• 12 локальных дисков до 2 ТБ в конфигурации RAID 6 (без hot spare)
• 16 внешних дисков до 2 ТБ в RAID 6 (вместе с hot spare)
• VMware поддерживает максимальный размер тома VMFS-5 size до 24 ТБ на хост в VSA 5.1
• 36 ТБ полезной емкости на 3 хоста

Ранее, в VSA 1.0, установка vCenter не поддерживалась на хранилищах узлов, входящих в VSA-кластер. Теперь можно устанавливать vCenter на одно из локальных хранилищ серверов, не входящее в общее пространство VSA. В этом случае, при создании общей емкости VSA можно выставить размер общего пространства, оставив нужное место на локальном VMFS под vCenter:

Эта же возможность относится и к установке VSA на существующих хостах ESXi, где на локальных дисках уже есть виртуальные машины. Администратор сначала создает общее пространство VSA на хостах кластера, а потом с помощью Cold Migration переносит в общий том VMFS эти виртуальные машины. Освободившееся место можно присоединить к пространству VSA за счет функции увеличения емкости.

Емкость хранилищ VSA может быть увеличена на лету за счет добавления новых дисков. Можно добавить новый Extent к тому VMFS, а можно пересоздать RAID и сихнронизировать его с другим узлом кластера:

Также теперь с одного сервера vCenter можно управлять сразу несколькими кластерами VMware VSA, каждый из которых состоит из двух или трех узлов. Таких кластеров может быть до 150 штук для одного vCenter. Это хорошо подходит для организаций, имеющих распределенную инфраструктуру филиалов, где, как известно, денег на покупку общих систем хранения обычно нет (ROBO-сценарии).

Модуль VMware VSA 5.1 можно использовать для различных сценариев и всех изданий VMware vSphere 5, кроме самого низшего - Essentials:

Возможности продукта для всех изданий полностью идентичны, кроме того, что VSA for Essentials Plus не может управлять несколькими кластерами VSA, поскольку очевидно, что нужна лицензия vCenter Standard. Если же VSA 5.1 используется для Essentials Plus в конфигурации ROBO (то есть, несколько сайтов, объединенных единой точкой управления) - то так делать можно.

Кстати о лицензии на vCenter Standard - раньше для пользователей Essentials Plus она временно требовалась, когда вы заменяли один из узлов кластера. Теперь такой необходимости нет.

На эту тему можно также почитать документ "What's New in VMware vSphere Storage Appliance 5.1".

В конце прошлой недели компания StarWind Software объявила о выпуске своего флагманского продукта StarWind iSCSi SAN 6.0, предназначенного для создания двух- или треузловых отказоустойчивых кластеров хранилищ для VMware vSphere и Hyper-V.

Новые возможности StarWind iSCSI SAN 6.0:

• Возможность создания треузловых кластеров хранищ, что позволяет повысить уровень отказоустойчивости, производительности и надежности, а также более эффективно использовать дисковое пространство (RAID0 вместо RAID6). При этом все три узла являются активными и на них идет запись. По трем каналам синхронизации данные хранилищ синхронизируются между собой. Также все узлы обмениваются друг с другом сигналами доступности (Heartbeat).
• Репликация на удаленный iSCSI Target через WAN-соединение с поддержкой дедупликации в конфигурации резервирования N+1. Об этом мы подробно писали тут.
• Асинхронная репликация для дедуплицированных хранилищ. Любой iSCSI target может быть использован как хранилище назначения для репликации.
• Поддержка Scale-Out File Servers в Windows Server 2012. Подробнее об этом здесь.
• Поддержка механизмом дедупликации данных, которые удаляются с хранилищ - неиспользуемые блоки перезаписываются актуальными данными.
• Использование памяти механизмом дедупликации сократилось на 30%. Теперь необходимо 2 МБ памяти на 1 ГБ дедуплицируемого хранилища при использовании блока дедупликациии 4 КБ.
• Улучшенное управление HA-устройствами. Теперь можно добавить новый узел кластера StarWind к HA-устройству, удалить узел или переключиться между ними без необходимости заново пересоздавать HA Device.
• HA-устройство может использовать другие типы устройств StarWind для хранения данных. Это может быть дедуплицированный диск, "тонкое" устройство IBV или устройство типа DiskBridge.
• Возможность загрузки бездисковых серверов по iSCSI для хранилищ StarWind. Подробно процедура настройки этой функции описана в документе "StarWind iSCSI Boot".
• Улучшенное резервное копирование для виртуальных машин VMware ESX/ESXi.
• StarWind SMI-S agent, доступный для загрузки как отдельный компонент. Он позволяет интегрировать StarWind в инфраструктуру Systme Center Virtual Machine Manager (SC VMM), добавив StarWind Storage Provider, реализующий задачи управления таргетами и хранилищами.
• Появилась полноценная поддержка механизма ALUA, работа с которым идет через SATP-плагин VMW_SATP_ALUA (подробнее об этом тут).
• Некоторые дополнительные возможности для резервного копирования виртуальных машин на Hyper-V.
• Новый GUI для управления процессом резервного копирования (интегрирован в Management Console).
• Упрощенный процесс подключения серверов Hyper-V и ESXi.

Ну и главное, что в релизной версии появился VMware Backup Plugin для резервного копирования виртуальных машин VMware vSphere (он приобретается отдельно как дополнение).

Более подробно о новых возможностях StarWind iSCSI SAN 6.0 можно узнать на странице продукта. Сравнение изданий доступно тут, а сделать запрос на приобретение решения можно здесь.

Мы уже немало рассказывали о развертывании и администрировании средства vGate R2, которое предназначено для защиты виртуальной инфраструктуры VMware vSphere средствами политик безопасности и механизма защиты от несанционированного доступа. На данный момент на рынке это единственное сертифицированное средство защиты инфраструктуры виртуализации, позволяющее обеспечить комплексную защиту серверов ESXi и виртуальных машин. Сегодня мы расскажем о том, как добавить инфраструктурные серверы (AD, DNS и т.п.) в защищенный периметр vGate R2.

Мы уже писали о новых возможностях VMware vSphere 5.1 - серверной платформы виртуализации, которая была анонсирована и выпущена на конференции VMowrld 2012. Вместе с выпуском обновленной версии продукта компания VMware внесла достаточно много изменений в издания и политики лицензирования продукта, так как почувствовала сильное давление со стороны основного конкурента - платформы Hyper-V в новой версии ОС Windows Server 2012 со множеством новых возможностей, по совокупности которых инфраструктура Microsoft почти не уступает VMware vSphere.

Итак, основные изменения в изданиях и лицензировании VMware vSphere 5.1:

• Полная отмена лимитов по vRAM и числу ядер для лицензии на процессор. Напомним, что ранее (в vSphere 5.0) при превышении суммарного значения сконфигурированной оперативной памяти виртуальных машин (vRAM) для лицензии на процессор определенного издания, пользователи были вынуждены докупать еще лицензий, чтобы соответствовать условиям VMware. Эта политика и раньше вызывала очень много вопросов, так как демотивировала пользователей наращивать коэффициент консолидации виртуальных машин на хостах VMware ESXi (превышаешь порог по памяти для лицензии->платишь больше), что противоречит самой идее виртуализации. Теперь этих ограничений нет, единица лицензирования - физический процессор сервера, при этом не важно сколько в нем ядер и памяти у самого сервера. Мы писали об этом тут.
• Во всех изданиях vSphere 5.1, начиная с Essentials Plus, появился виртуальный модуль vSphere Storage Appliance 5.1. Об этом продукте мы уже писали вот тут. Нужен он для создания общего хранилища под виртуальные машины, которое можно создать на базе локальных дисков серверов. Этот продукт обновился и теперь доступен для построения распределенной архитектуры кластеров хранилищ, управляемых через один vCenter.
• Издание VMware vSphere 5.1 Standard приобрело множество возможностей. К ним относятся: механизм резервного копирования vSphere Data Protection (подробнее здесь), "горячее" добавление устройств виртуальной машины Hot Add, фреймворк антивирусной защиты vShield Endpoint, возможность репликации виртуальных машин vSphere Replication, кластеры непрерывной доступности vSphere Fault Tolerance и, главное, механизм "горячей" миграции хранилищ виртуальных машин vSphere Storage vMotion.
• Издание VMware vSphere 5.1 Essentials Plus приобрело множество возможностей. К ним относятся: механизм резервного копирования vSphere Data Protection (подробнее здесь), фреймворк антивирусной защиты vShield Endpoint и возможность репликации виртуальных машин vSphere Replication.
• Важный момент: пользователи vSphere 5.0 теперь не имеют ограничений по vRAM. То есть, изменения в лицензированию имеют обратную силу.
• Издание VMware vSphere 5.1 Enterpise Plus позволяет иметь до 64 vCPU виртуальных машин.
• Доступна новая ветка издания VMware vSphere 5.1 Standard with Operations Management. Это издание включает в себя продукт vCenter Operations Management Suite Advanced, а также средство обновления гостевых ОС vCenter Protect Standard.

Как и всегда, пользователи VMware vSphere 5.0 с действующей подпиской и поддержкой (SnS) обновляются на VMware vSphere 5.1 бесплатно.

Все издания продукта VMware vCenter (Essentials, Foudation и Standard) включают в себя следующие возможности:

• Management service – централизованная консоль управления.
• Database server – сервер БД.
• Inventory service – сервис поиска по виртуальной инфраструктуре, в том числе с несколькими vCenter, а также средства кэширования запросов клиентов, что повышает производительность.
• VMware vSphere Clients - "толстая" и "тонкая" консоли администрирования (Web Client теперь основной), позволяющие управлять несколькими vCenter одновременно.
• VMware vCenter APIs and .NET Extension – интеграция vCenter со сторонними плагинами.
• vCenter Single Sign-On – возможность единовременного логина на сервер без необходимости вводить учетные данные в различных сервисах управления виртуальной инфраструктурой.

Издание Standard, помимо возможности управления неограниченным количеством хост-серверов, предоставляет следующие возможности:

• vCenter Orchestrator – средство автоматизации рабочих процессов в виртуальной инфраструктуре.
• vCenter Server Linked Mode – общее окружение для нескольких серверов vCenter Server.

Традиционная таблица сравнения функциональности изданий VMware vSphere 5.1, приобретаемых поштучно на процессор:

Сравнение возможностей	vSphere 5.1 Standard	vSphere 5.1 Enterprise	vSphere 5.1 Enterprise Plus
Компоненты продукта
Единица лицензирования	На 1 CPU	На 1 CPU	На 1 CPU
Объем vRAM	Не ограничено	Не ограничено	Не ограничено
Максимальное количество vCPU виртуальной машины	8	32	64
SUSE Linux Enterprise Server for VMware
Средство управления vCenter Server	vCenter Server Foundation  vCenter Server Standard	vCenter Server Foundation  vCenter Server Standard	vCenter Server Foundation  vCenter Server Standard
Возможности продукта
vSphere Hypervisor (платформа ESXi)
Thin Provisioning
Update Manager
Data Protection
High Availability
vMotion
vStorage APIs for Data Protection
Hot Add
vShield Zones
vShield Endpoint
Replication
Fault Tolerance
Storage vMotion
Virtual Serial Port Concentrator
Storage APIs for Array Integration
Storage APIs for Multipathing
Distributed Resources Scheduler (DRS), Distributed Power Management (DPM)
Storage I/O Control и Network I/O Control
Distributed Switch
Host Profiles и Auto Deploy
Storage DRS и Profile-Driven Storage

Традиционная таблица комплектов лицензий VMware vSphere 5.1 Essentials, VMware vSphere 5.1 Essentials Plus, VMware vSphere 5.1 Acceleration Kits:

Сравнение возможностей	Essentials Kit	Essentials Plus Kit	Standard  Acceleration Kit	Standard with Operations Management Kit	Enterprise  Acceleration Kit	Enterprise Plus  Acceleration Kit
Компоненты продукта
Средство управления vCenter Server	vCenter Server Essentials	vCenter Server  Essentials	vCenter Server Standard	vCenter Server Standard	vCenter Server Standard	vCenter Server Standard
Возможности общего хранилища на локальных дисках (Shared Storage)		vSphere Storage Appliance for Essentials Plus	vSphere Storage Appliance	vSphere Storage Appliance	vSphere Storage Appliance	vSphere Storage Appliance
Включенные лицензии в пакет	3 сервера, в каждом максимум 2 процессора	3 сервера, в каждом максимум 2 процессора	6 процессоров с возможностью докупки лицензий по процессорам	6 процессоров с возможностью докупки лицензий по процессорам	6 процессоров с возможностью докупки лицензий по процессорам	6 процессоров с возможностью докупки лицензий по процессорам
Объем vRAM на процессор	Не ограничено	Не ограничено	Не ограничено	Не ограничено	Не ограничено	Не ограничено
Максимальное количество vCPU виртуальной машины	8	8	8	8	32	64
SUSE Linux Enterprise Server for VMware
Возможности продукта
vSphere Hypervisor (платформа ESXi)
Thin Provisioning
Update Manager
vStorage APIs for Data Protection
Data Protection
High Availability
vMotion
vShield Zones
vShield Endpoint
Replication
Storage vMotion
Fault Tolerance
Hot Add
Virtual Serial Port Concentrator
Storage APIs for Array Integration
Storage APIs for Multipathing
Distributed Resources Scheduler (DRS), Distributed Power Management (DPM)
Storage I/O Control и Network I/O Control
Distributed Switch
Host Profiles и Auto Deploy
Storage DRS и Profile-Driven Storage
VMware vCenter Operations Management Suite Advanced
VMware vCenter Protect Standard

Полный обзор политик лицензирования и условий поставки VMware vSphere 5.1 приведен в документе " vSphere 5.1 Licensing, Pricing and Packaging".

На конференции VMworld 2012 компания VMware анонсировала выпуск новой версии серверной платформы виртуализации VMware vSphere 5.1. В обновленной версии продукта появилось множество интересных возможностей, отражающих движение компании VMware в направлении развития облачных вычислений. В этой статье мы приведем полный список новой функциональности VMware vSphere 5.1, которая доступна пользователям уже сегодня...

На проходящем сейчас в Сан-Франциско VMworld 2012 компания VMware продемонстрировала новые горизонты производительности серверной платформы виртуализации, выжав 1 миллион операций ввода-вывода в секунду (IOPS) для одной виртуальной машины на VMware vSphere 5.1.

Для тестов использовалась следующая конфигурация:

Hypervisor: vSphere 5.1
Server: HP DL380 Gen8
CPU: 2 x Intel Xeon E5-2690, HyperThreading disabled
Memory: 256GB
HBAs: 5 x QLA2532
Storage: 2 x Violin Memory 6616 Flash Memory Arrays
VM: Windows Server 2008 R2, 8 vCPUs and 48GB.
Iometer Config: 4K IO size w/ 16 workers

Напомним, что на прошлом VMworld 2011 также была показана производительность в 1 миллион IOPS (300 000 для одной машины), но для хост-сервера VMware ESXi (суммарно от нескольких виртуальных машин).

Также из любопытных фактов, озвученных на VMworld 2012:

• 60% серверов уже являются виртуальными, VMware стремится к показателю 90% и более.
• Число сертифицированных специалистов VMware VCP достигло 125 тысяч.
• В VMworld 2012 приняли участие 20 000 специалистов.
• Основная концепция на ближайшее будущее - "Software-defined data center" (по аналогии с приобретенной недавно концепцией компании Nicira - Software-defined networking). Предполагается, что ключевые позиции в этой концепции займут продукты VMware vSphere, vCloud Director, vCloud Connector, Site Recovery Manager, vCenter Operations и vFabric Application Director.

Больше об облачных инициативах VMware - в самое ближайшее время.

Мы уже писали о продукте ПАК "Соболь", который представляет собой специальную плату с соответствующим программным обеспечением, позволяющую физически защищать хост-серверы VMware ESXi от несанкционированного доступа. Совместно с сертифицированным средством vGate R2, которое автоматически настраивает безопасную конфигурацию хостов и виртуальных машин, данный продукт позволяет построить комплексную инфраструктуру защиты виртуальной среды.

ПАК «Соболь» версии 3.0 реализует следующие защитные механизмы:

• идентификация и аутентификация пользователей на входе в систему (непосредственно при запуске сервера);
• ведение журнала безопасности;
• сигнализация попыток нарушения защиты;
• запрет загрузки с внешних носителей;
• контроль конфигурации (PCI-устройств, ACPI, SMBIOS и оперативной памяти).

На эту тему у компании Код Безопасности есть специальная брошюра: "vGate R2 и ПАК «Соболь» - надежная защита виртуальной инфраструктуры на платформе VMware vSphere 5", где можно почитать об основных проблемах контроля целостности хост-серверов VMware ESXi и виртуальных машин и их доверенной загрузки.

4 сентября в 11:00 мы приглашаем вас на бесплатный вебинар "ПАК "Соболь" - настоящее и будущее", где будут подробно рассмотрены новые возможности ПАК «Соболь», отличия от предыдущих версий и дальнейшее развитие продукта. Там вы сможете задать все интересующие вас вопросы о физической защите хост-серверов VMware ESXi в вашей компании.

Зарегистрироваться.

Не так давно мы писали про мартовские, июньские и июльские превью-версии VMware Workstation и VMware Fusion 2012 года. Вчера компания VMware, проведя обширное бета-тестирование, выпустила окончательные версии продуктов VMware Workstation 9 и VMware Fusion 5, получившие много новых интересных возможностей.

Полный список новых возможностей VMware Workstation 9:

• Поддержка гостевых и хостовых ОС Windows 8 и Windows Server 2012. Упрощенная установка, распознающая Windows 8. В гостевой ОС поддерживается новый интерфейс Metro. Переключение между Metro и хостовым десктопом может быть произведено нажатием кнопки Windows, при этом интерфейс Unity интеллектуально обрабатывает Metro. В Workstation 9 также присутствует поддержка мультитача для гостевой ОС Windows 8 с Metro, работающей в Workstation, которая запущена на планшете с Windows 8.
• Улучшения графического движка. В Workstation 9 было сделано много улучшений в структуре движка, включая графический драйвер для рендера графики в Windows 8 без аппаратного ускорения, улучшения графического отображения "тяжелых" приложений (AutoCAD и SolidWorks), а также существенная доработка графического драйвера для Windows XP.
• Поддержка движка OpenGL для гостевых ОС Linux. VMware разработала собственный драйвер для OpenGL графики и добавила его на X.org. Это позволит использовать новые графические возможности в текущих и новых дистрибутивах Linux (например, Ubuntu 12.04) без необходимости установки VMware Tools.
• Restricted Virtual Machines - возможность задать дополнительный пароль для зашифрованных ВМ, чтобы предотвратить изменение их конфигурации со стороны неавторизованных пользователей (например, ВМ для студентов). Такие машины могут работать в VMware Workstation 9, VMware Player 5 и VMware Fusion 5 на платформах Windows, Linux или Mac.
• WSX Server - это технология, которая работает на базе стандарта HTML 5 (с поддержкой WebSockets), что подразумевает отсутствие необходимости иметь какие-либо дополнительные компоненты, кроме веб-браузера, чтобы получить доступ к консоли виртуальной машины и ее средствами управления. В качестве веб-браузеров, той или иной степени совместимых с HTML 5, можно использовать Chrome 17, Firefox 10, IE 10, Safari 5 на ПК с Mac OS и iOS 5 для iPad. На данный момент эта функция не поддерживается в производственной среде. Для PC рекомендуется использовать браузер Google Chrome 17, а для Mac и iPad - Apple Safari 5 (на данный момент есть проблемы с Internet Explorer 10). WSX также работает и с другими браузерами на планшетах Android под управлением Ice Cream Sandwich, однако пока не все из них протестированы.
• Возможность загрузки виртуальных машин на хосты VMware vSphere и обратно с них на Workstation - это также возможно сделать, перетаскивая их с удаленного хоста в секцию My Computer библиотеки Virtual Machine Library.
• Поддержка USB 3.0 - Workstation 9 поддерживает проброс USB 3.0 устройств в гостевую ОС Windows 8. Делается это средствами новых драйверов USB 3.0 для накопителей или видеоустройств.
• Улучшения Nested Virtualization - были улучшены расширения аппаратной виртуализации Intel VT-x/EPT и AMD-V/RVI, что позволяет запускать ESX/ESXi в гостевой ОС, а в них 64-битные машины с меньшими потерями производительности. Если вы включали эти расширения в Workstation 8, то перед обновлением до девятой версии их надо выключить, а после обновления снова включить.
• Hyper-V можно запускать в гостевой ОС - можно использовать Windows 8 с функциями Hyper-V, а также Hyper-V Server 2012 или Windows Server 2012 с ролью Hyper-V. Эти возможности не поддерживаются в производственной среде (и никогда не будут).
• Virtual Performance Counters - счетчики производительности виртуальных машин для профилирования приложений из гостевой ОС (например, с помощью Intel vTune).
• Remoting Improvements - существенные улучшения производительности при соединении с консолью ВМ на VMware vSphere или к машинам Workstation с помощью VNC-клиента.
• Disk Cleanup - новая возможность почистить место в папке с файлами виртуальной машины.
• Quick Switch II - раньше в Workstation был режим быстрого переключения между виртуальными машинами вверху окна, в Workstation 8 этот функционал был убран. Теперь он вернулся с большим удобством и группировкой по хостам в хостовых ОС Windows.
• Thumbnail Actions - теперь на таскбаре для виртуальных машин есть кнопки для управления питанием ВМ.
• Saved Filters - в Workstation 9 автоматически сохраняются поиски по virtual machine library как фильтры для быстрого их применения при следующем запуске.
• VMware Player - пользовательский интерфейс этого продукта был полностью переработан. Теперь он также доступен и для коммерческого использования - лицензия на VMware Player 5 включена в издание VMware Fusion 5 Professional.
• Поддержка шифрованного SSL-соединения для WSX. Теперь можно назвать сертификаты именами wsx.crt и wsx.key и положить их в папки etc/vmware/wsx/ssl/directory (Linux) или Application Data\VMware\VMware WSX\SSL (Windows). Этого не сделано по умолчанию, так как SSL глючит с WebSockets.
• Улучшена стабильность продукта, включая операции suspend/resume и display, а также улучшена поддержка устройств хоста.
• Поддержка голосового движка через WSX на Mac OS и iOS при работе с консолью ВМ Windows.

Release Notes и документация к продукту VMware Workstation 9 доступна по этой ссылке. Скачать пробную версию можно тут. Для пользователей VMware Workstation 8 обновление на девятую версию - бесплатно.

Полный список новых возможностей VMware Fusion 5:

• Упрощенная установка - нужно просто запустить VMware Fusion.app или перетащить его в место установки, для удаления продукта можно перетащить иконку в корзину.
• Поддержка Windows 8 в виртуальных машинах - Fusion 5 полностью поддерживает интерфейс Metro в гостевой ОС Windows 8, имеет отдельный профиль клавиатуры, а также возможность импорта физических ПК в ВМ. Поддерживается также установка Windows 8 в режиме "Boot Camp".
• Поддержка VMware ESXi 5, Ubuntu 12.04, Fedora 17 и Windows Server 2012 в гостевых ОС.
• Полная поддержка хостов и дизайн для OS X Mountain Lion - VMware Fusion использует Mountain Lion notification center для отображения важных сообщений. Кроме этого можно искать Windows-программы в Launchpad, а также использовать "AirPlay Mirroring" для стриминга приложений Windows на HDTV.
• Улучшенная стабильность - при работе с приложениями для Windows 7 и Windows 8.
• Оптимизация для последних устройств Mac - поддержка десплеев Retina, интерфейса USB 3.0 для Windows и Linux, SSD-оптимизации, а также экономия батареи.
• Множественные изменения интерфейса:
  • Новая библиотека виртуальных машин (virtual machine library) и куча возможностей в ней.
  • Новый механизм работы с окнами VMware Fusion (настройки, снапшоты и т.п.).
  • Запуск приложений Windows 7 и Windows 8 в режиме Unity.
  • Прямой доступ к VMware Fusion Learning Center.
• Поддержка ВМ с гостевой ОС Linux и 3D desktops - включая Ubuntu 12.04 и последние релизы OpenSUSE и поддержка OpenGL.
• Restricted virtual machines - поддержка запуска и создания защищенных ВМ (см. раздел Workstation 9).
• Virtual Performance Counter - счетчики производительности виртуальных машин для профилирования приложений из гостевой ОС (например, с помощью Intel vTune).
• Custom network configuration - возможность создания специализированных сетей для лаборатории, демонстраций и тестирования.
• Улушчение производительности и надежности операций suspend, resume, pause, restart.
• Импорт виртуальных машин в OVF-формате.
• Изменение загрузочных устройств виртуальных машин Mac OS X.
• Улучшения при работе с устройствами ВМ.
• Улучшения виртуализации инструкций VT-x/EPT.
• Новый VIX API для автоматизации через perl или другие скриптовые языки.
• Поддержка сетевой загрузки виртуальных машин на основе EFI.
• Метапакеты (mpkg) для развертывания VMware Fusion на большом количестве компьютеров Mac.

Release Notes и документация к продукту VMware Fusion 5 доступна по этой ссылке. Скачать пробную версию можно тут.

Уже совсем скоро в Сан-Франциско состоится коференция VMworld 2012, которую ежегодно проводит компания VMware для всех тех, кому интересны технологии виртуализации и облачные инфраструктуры. Там мы увидим много интересных анонсов и изменений в продуктовой линейке VMware, однако один важный анонс уже, по-сути, сделан: VMware отменит ограничения по vRAM для лицензий различных изданий VMware vSphere 5.1, обновленной версии лидирующей на рынке платформы виртуализации. Напомним, что при превышении суммарного значения сконфигурированной оперативной памяти виртуальных машин (vRAM) для лицензии на процессор, пользователи сейчас вынуждены докупать еще лицензий, чтобы соответствовать условиям VMware. Эта политика и раньше вызывала очень много вопросов, так как демотивировала пользователей наращивать коэффициент консолидации виртуальных машин на хостах VMware ESXi (превышаешь порог по памяти для лицензии->платишь больше), что противоречит самой идее виртуализации.

Очевидно, что решение об отмене лицензирования по vRAM было принято под давлением того факта, что платформа Microsoft Hyper-V 3.0, которая вышла вместе с обновленной ОС Windows Server 2012, окажется практически эквивалентной по большинству функциональных возможностей платформе VMware vSphere. А как мы уже писали, виртуальная инфраструктура на базе Hyper-V+SC VMM обойдется гораздо дешевле оной от VMware.

То отклонение красного графика в результатах калькулятора Microsoft, выраженное в деньгах, которое мы видим при увеличении коэффициента консолидации, и есть тот самый vRAM Tax - налог, который пользователи плятят за то, что более эффективно загружают свои хост-серверы.

Пользователи отреагировали на отмену налога весьма положительно:

Все это, конечно, хорошо, но этого мало. Даже с отмененным налогом на vRAM компания VMware не сможет противостоять ценовому давлению Microsoft в сегменте малого и среднего бизнеса, поэтому в ближайшее время мы увидим несколько значимых изменений в лицензионной политике VMware именно для СМБ (пока не скажу каких).

Также, чтобы нивелировать старания Microsoft по раскрутке встроенной в Hyper-V технологии репликации виртуальных машин между хостами Hyper-V Replica, VMware исключит vSphere Replication из состава VMware Site Recovery Manager и включит ее в состав самой платформы vSphere 5.1.

Кроме этого, мы увидим Shared-nothing горячую миграцию виртуальных машин между хостами (без общего хранилища) - то, что важно для пользователей СМБ, и то, что уже сделано в Hyper-V.

По всем этим потугам мы видим, что VMware начинает пытаться отбиваться от Microsoft (невероятно, да - VMware все-таки заметила, что у нее есть СМБ-пользователи), однако если цены на vSphere для небольших компаний не будут снижены (или не будут выпущены какие-нибудь особенные спецпредложения) - VMware потеряет этот рынок.

Не так давно обновились сразу несколько продуктов VMware и Microsoft, о которых мы расскажем в этой заметке. Во-первых, вышло обновление VMware vCenter 5.0 Update 1b (напомним, что не так давно вышло обновление 1a).

VMware vCenter Server 5.0 Update 1b - это патч-релиз, имеющий следующие улучшения:

• Поддержка следующих СУБД для vCenter:
• Oracle 11g Enterprise Edition, Standard Edition, Standard ONE Edition Release 2 [11.2.0.3] - 64 bit
• Oracle 11g Enterprise Edition, Standard Edition, Standard ONE Edition Release 2 [11.2.0.3] - 32 bit
• Смена БД vCenter Server Appliance - встроенная база данных DB2 Express теперь заменена на VMware vPostgres.
• Исправления ошибок, приведенные тут.

Во-вторых, вышел минорный апдейт продукта VMware View 5.1.1 (о версии View 5.1 мы уже писали тут). Этот релиз исправляет только некоторые ошибки в компонентах View Connection Server, View Agent и View Persona Management. Соответственно, вам не нужно обновлять компоненты View Security Server, View Transfer Server и View Composer Server. Также появился документ "Obtaining SSL Certificates for VMware View Servers". Основные улучшения касаются представлений View Manager, когда у вас большое количество виртуальных ПК в VDI-инфраструктуре (>10 000), которые разбиты на блоки, в соответствии с референсной архитектурой:

В-третьих, компания Microsoft добавила ОС Windows Server 2012 в галерею виртуальных машин Windows Azure.

Бесплатный доступ к Windows Azure в течение 30 дней можно получить без кредитной карты и прочих платежных данных на сайте официального дистрибьютора сервисов Azure, а если вы хотите триал на 90 дней, то понадобится указать данные кредитной карты, которая оформлена в США, и будьте готовы заплатить за превышение указанных в условиях лимитов использования вычислительных ресурсов.

В-четвертых, компания Microsoft выпустила обновление утилиты Virtual Machine Servicing Tool 2012. Об этой утилите мы уже писали тут.

Напомним, что это средство необходимо в случаях, когда требуется обновление выключенных виртуальных машин (например, эти машины используются редко, но для них в целях безопасности нужно поддерживать необходимый уровень обновлений). Утилита VMST 2012 предназначена для совместной работы с System Center 2012 Virtual Machine Manager (VMM), System Center 2012 Configuration Manager и Windows Server Update Services (WSUS) 3.0 SP2.

Ну и также из последнего - Hyper-V в Windows Server 2012 поддерживает FreeBSD.

Компания StarWind Software объявила о выпуске публичной бета-версии решения номер 1 для создания отказоустойчивых хранилищ для серверов VMware vSphere и Microsoft Hyper-V - StarWind iSCSI SAN 6.0.

О версии StarWind 5.9 мы уже писали, так вот она, не перетекая в релиз, превратилась в бету StarWind iSCSI SAN 6.0, чтобы выйти уже со всеми новыми возможностями в мажорном обновлении.

Новые возможности StarWind iSCSI SAN 6.0:

• Улучшенное управление HA-устройствами. Теперь можно добавить новый узел кластера StarWind к HA-устройству, удалить узел или переключиться между ними без необходимости заново пересоздавать HA Device.
• HA-устройство может использовать другие типы устройств StarWind для хранения данных. Это может быть дедуплицированный диск, "тонкое" устройство IBV или устройство типа DiskBridge.
• Асинхронная репликация для дедуплицированных хранилищ. Любой iSCSI target может быть использован как хранилище назначения для репликации.
• Возможность загрузки бездисковых серверов по iSCSI для хранилищ StarWind. Подробно процедура настройки этой функции описана в документе "StarWind iSCSI Boot".
• Улучшенное резервное копирование для виртуальных машин VMware ESX/ESXi.
• Некоторые дополнительные возможности для резервного копирования виртуальных машин на Hyper-V.
• Новый GUI для управления процессом резервного копирования (интегрирован в Management Console).
• Упрощенный процесс подключения серверов Hyper-V и ESXi.

Скачать бета-версию StarWind iSCSI SAN 6.0 можно по этой ссылке. Более подробно о новых возможностях можно прочитать на форуме.

Мы уже писали о продукте VMware vSphere Storage Appliance, который позволяет организовать отказоустойчивую инфраструктуру хранилищ на базе локальных дисков хост-серверов VMware ESXi, которые реализуют общее хранилище за счет зеркалирования томов и экспорта хранилищ хостам по протоколу NFS. Узлы ESXi с использованием VSA могут образовывать двух- или трехузловой кластер:

В случае, например, использования двухузлового кластера VSA совместно с технологией VMware Fault Tolerance, может возникнуть такая ситуация - когда Primary VM находится на хосте ESXi и использует основную копию тома с его локальных дисков. В случае сбоя этого хоста возникает двойной отказ - и виртуальной машины, которая на нем исполняется, и ее хранилища, так как оно находилось на дисках хоста. В этом случае возникает неизбежный простой ВМ до того момента, как подхватится хранилище с другого хоста и Secondary VM сможет его использовать.

В такой ситуации VMware рекомендует поступать так:

А именно: размещать хранилище защищенной FT виртуальной машины (ее виртуальные диски и файлы) на хосте, отличном от того, на котором она исполняется, т.е. на том хосте ESXi, где исполняется Secondary VM. В этом случае при любом отказе двойного сбоя не будет - всегда выживет или исполняющаяся ВМ или ее хранилище, которое подхватится Secondary VM.

В случае трехузловой конфигурации VSA можно пойти дальше: разместить Primary VM на одном узле, Secondary VM на другом, а файлы этой ВМ на третьем узле кластера VSA.

Если в VMware vSphere Client вы зайдете на вкладку "Configuration", далее в разделе "Hardware" выберете пункт "Power Management", то увидите вот такую картинку:

Это настройки управления питанием хост-сервера VMware ESXi. Они задают политики управления питанием на основе открытого стандарта Advanced Configuration and Power Interface (ACPI), который определяет схему электропотребления на основе состояний процессора: Power Performance States (P-states) и Processor idle sleep states (C-states).

Режимы P-states — это комбинации напряжений и частот работы ядра процессора для различных типов нагрузок на CPU. Правильно выставленная пара «напряжение—частота» позволяет определить необходимую производительность для выполнения текущих задач CPU, что позволет снизить его энергопотребление и тепловыделение. Состояния P-states являются подмножеством рабочего C-state состояния C0.

Режимы C-states — это состояния, в которых процессор находится в различной ситуации относительно его простоя. Например, C1 (Halt) - состояние, когда процессор не исполняет инструкции, но готов мгновенно (с задержкой примерно 10нс) приступить к их исполнению, C2 (Stop-Clock) - состояние, в котором процессор по-прежнему поддерживает актуальное внутреннее состояние, но просыпается большее (до 100нс) время, при этом дополнительно отключены буферы ввода-вывода. C3 (Sleep) - состояние, в котором процессор отключает питание кэшей второго уровня, но сохраняет прочую служебную информацию. Время пробуждения может составлять до 50 мкс. В современных процессорах есть также множество дополнительных состояний, например, C1E с меньшим энергопотреблением и C6 - когда рабочее напряжение на процессоре может быть понижено до нуля.

Теперь, что мы увидим если нажмем на ссылку "Properties" для Power Management Settings:

Вот что значат эти политики:

• High performance - данная политика максимизирует производительность процессора за счет его поддержки в наивысшем P-state состоянии все время (то есть, по-сути политика энергосбережения отключена). При этом используются только 2 C-state состояния: С0 (running) и C1 (halted). Соответственно, данный режим выдает максимальную производительность, не имеет инерционности и потребляет больше всего энергии. Эта политика выставлена по умолчанию для VMware ESX/ESXi 4.0 и 4.1.
• Balanced - эта политика разработана для того, чтобы максимально использовать переключения между P-states в целях экономии энергии. Она обладает слегка большей инерционностью, но почти не влияет на производительность. Эта политика выставлена по умолчанию для VMware ESXi 5.0.
• Low Power - эта политика придумана для максимального энергосбережения, а значит имеет риски по потере хостом ESXi производительности CPU. Она активно использует состояния C-states при различных видах простоя процессора.
• Custom - по умолчанию эта политика работает как Balanced, но позволяет настроить различные параметры пользователю. Если оборудование хоста не позволяет операционной системе самостоятельно управлять энергопотреблением, то для этой политики будут доступны только варианты Not Supported или High performance.

Определять политики вручную необходимо только тогда, когда вы точно знаете, что с ними делать. Вот, например, табличка, описывающая custom-параметры политики:

О том, как использовать эти настройки, и как они влияют на энергопотребление процессоров, можно прочитать в документе "Host Power Management in VMware vSphere 5".

Недавно мы уже писали о том, как работает технология балансировки нагрузки на хранилища VMware Storage DRS (там же и про Profile Driven Storage). Сегодня мы посмотрим на то, как эта технология работает совместно с различными фичами дисковых массиов, а также функциями самой VMware vSphere и других продуктов VMware.

Для начала приведем простую таблицу, из которой понятно, что поддерживается, а что нет, совместно с SDRS:

Комментарии к таблице:

• Снапшоты на уровне массива - они никак не влияют на работу механизма SDRS, однако рекомендуется оставить его в ручном режиме, чтобы избежать возможных проблем при одновременном создании снапшота и перемещении виртуальных дисков.
• Дедупликация на уровне массива - полностью совместима со механизмом SDRS, однако рекомендуется ручной режим, так как, с точки зрения дедупликации, наиболее эффективно сначала применить рекомендации по миграции виртуальных дисков, а потом уже использовать дедупликацию (для большинства сценариев).
• Использование array-based auto-tiering - очевидно, что функции анализа производительности в дисковом массиве и перемещения данных по ярусам с различными характеристиками могут вступить вступить в конфликт с алгоритмами определения нагрузки в SDRS и перемещения vmdk-дисков по хранилищам на логическом уровне. Сам Storage DRS вступает в действие после 16 часов анализа нагрузки и генерирует рекомендации каждые 8 часов, в дисковом же массиве механизм перераспределения блоков по ярусам может работать по-разному: от real-time процесса в High-end массивах, до распределения каждые 24 часа в недорогих массивах. Понятно, что массиву лучше знать, какие блоки куда перемещать с точки зрения производительности физических устройств, поэтому для SDRS рекомендуется оставить выравнивание хранилищ только по заполненности томов VMFS, с отключенной I/O Metric.
• Репликация на уровне массива - полностью поддерживается со стороны SDRS, однако, в зависимости от использования метода репликации, во время применения рекомендаций SDRS виртуальные машины могут остаться в незащищенном состоянии. Поэтому рекомендуется применять эти рекомендации SDRS во время запланированного окна обслуживания хранилищ.
• VMware vSphere Storage Metro Cluster - здесь нужно избегать ситуации, когда виртуальный диск vmdk машины может уехать на другой сайт по отношению к хосту ESXi, который ее исполняет (когда используется общий Datastore Cluster хранилищ). Поэтому, а еще и потому, что распределенные кластеры могут строиться на базе технологий синхронной репликации хранилищ (см. предыдущий пункт), нужно использовать ручное применение рекомендаций SDRS.

• Поддержка VMware vSphere Site Recovery Manager - на данный момент SDRS не обнаруживает Datastore Groups в SRM, а SRM не отслеживает миграции SDRS по хранилищам. Соответственно, при миграции ВМ на другое хранилище не обновляются protection groups в SRM, как следствие - виртуальные машины оказываются незащищенными. Поэтому совместное использование этих продуктов не поддерживается со стороны VMware.
• Поддержка томов RDM - SDRS полностью поддерживает тома RDM, однако эта поддержка совершенно ничего не дает, так как в миграциях может участвовать только vmdk pointer, то есть прокси-файл виртуального диска, который занимает мало места (нет смысла балансировать по заполненности) и не генерирует никаких I/O на хранилище, где он лежит (нет смысла балансировать по I/O). Соответственно понадобиться эта поддержка может лишь на время перевода Datastore, где лежит этот файл-указатель, в режим обслуживания.
• Поддержка VMware vSphere Replication - SDRS не поддерживается в комбинации с хостовой репликацией vSphere. Это потому, что файлы *.psf, используемые для нужд репликации, не поддерживаются, а даже удаляются при миграции ВМ на другое хранилище. Вследствие этого, механизм репликации для смигрированной машины считает, что она нуждается в полной синхронизации, что вызывает ситуацию, когда репликация будет отложена, а значит существенно ухудшатся показатели RTO/RPO. Поэтому (пока) совместное использование этих функций не поддерживается.
• Поддержка VMware vSphere Snapshots - SDRS полностью поддерживает спапшоты виртуальных машин. При этом, по умолчанию, все снапшоты и виртуальные диски машины при применении рекомендаций перемещаются на другое хранилище полностью (см. левую часть картинки). Если же для дисков ВМ настроено anti-affinity rule, то они разъезжаются по разным хранилищам, однако снапшоты едут вместе со своим родительским диском (см. правую часть картинки).

• Использование тонких дисков VMware vSphere - полностью поддерживается SDRS, при этом учитывается реально потребляемое дисковое пространство, а не заданный в конфигурации ВМ объем виртуального диска. Также SDRS учитывает и темпы роста тонкого виртуального диска - если он в течение последующих 30 часов может заполнить хранилище до порогового значения, то такая рекомендация показана и применена не будет.
• Технология Linked Clones - не поддерживается со стороны SDRS, так как этот механизм не отслеживает взаимосвязи между дисками родительской и дочерних машин, а при их перемещении между хранилищами - они будут разорваны. Это же значит, что SDRS не поддерживается совместно с продуктом VMware View.
• Использование с VMware vCloud Director - пока не поддерживается из-за проблем с размещением объектов vApp в кластере хранилищ.
• Хосты с версией ПО, младше чем vSphere 5.0 - если один из таких хостов поключен к тому VMFS, то для него SDRS работать не будет. Причина очевидна - хосты до ESXi 5.0 не знали о том, что будет такая функция как SDRS.

Больше подробностей приведено в документе "VMware vSphere Storage DRS Interoperability".

Многие компании для защиты своей виртуальной инфраструктуры VMware vSphere используют сертифицированное средство vGate R2 (с поддержкой vSphere 5). Мы уже много писали о способах защиты и функциональности продукта для серверов виртуализации и виртуальных машин, исполняющих серверные нагрузки. В этой заметке, мы хотим рассказать о том, что продукт vGate R2 также поддерживает и инфраструктуру виртуальных ПК VMware View.

Архитектура использования vGate R2 совместно с VMware View похожа на оную с использованием виртуальных серверов, только защищается не vCenter, а View Connecton Server:

На компьютере, где установлен View Connection Server, должно быть не менее двух Ethernet-интерфейсов, один из которых будет подключен к внешнему периметру сети администрирования виртуальной инфраструктуры, а другой — к сети ВМ, где находятся рабочие места пользователей.

Для предоставления доступа View Connection Server к vCenter необходимо настроить определенный набор правил доступа к vCenter для учетной записи компьютера, где находится View Connection Server. Набор правил для предоставления доступа View Connection Server к vCenter содержится в шаблоне "Доступ View Connection сервера к vCenter".

В этом шаблоне указаны порты доступа View Connection Server к vCenter, заданные по умолчанию (8443 и 443). Если используются порты, отличные от стандартных, необходимо указать номера этих портов в правилах доступа. Если планируется поддержка View Client with Local Mode, то необходимо настроить еще одно правило для учетной записи компьютера, где находится View Connection Server. Это правило должно разрешить доступ к серверу ESXi, на котором исполняется ВМ с View Transfer Server, по TCP-порту 902.

В целях безопасности настоятельно не рекомендуется предоставлять доступ к другим объектам (или по другим портам) защищаемого периметра для учетной записи компьютера, где находится View Connection Server.

После настройки правил доступа перезапустите сервис vGate Client Authorization Service на сервере авторизации.

Не так давно мы писали про проект Boomerang, который доступен на сайте VMware Labs. Это утилита, которая размещается в трее и с помощью которой можно получать быстрый доступ к консоли виртуальных машин (через VMware Remote Console, VMRC) и управлению питанием. Машины можно помечать звездочками, чтобы выделить их в списке Favorites. К сожалению, Boomerang не работает для бесплатного VMware ESXi (см. комментарии), но поддерживает одновременное подключение к нескольким хост-серверам в платной версии.

На днях произошло обновление продукта до версии Boomerang 2.0.

Среди новых возможностей VMware Boomerang 2.0:

• Поддержка нескольких серверов View Connection Server одновременно и их виртуальных машин.
• При установке продукта поддержку VMware vSphere или VMware View можно опционально отключить.
• Сортировка серверов в алфавитном порядке.
• Если включен поиск ВМ, то список ВМ серверов автоматически раскрывается.

Напомним основные возможности продукта VMware Boomerang:

• Поддержка соединения к нескольким серверам ESX/ESXi и нескольким серверам vCenter одновременно.
• Поддержка соединения к нескольким серверам View Connection Server одновременно.
• Соединение с десктопами VMware View по протоколу PCoIP или RDP.
• Автоматическое перенаправление клиентских принтеров в десктопы View через ThinPrint.
• Сохранение логина и пароля для входа на серверы.
• Панель Favorites для удобства просмотра машин на нескольких серверах.
• Удобная панель управления питанием ВМ.
• Поиск машины в списке происходит набором ее имени на клавиатуре.
• Серверы с большим количеством ВМ автоматически сворачиваются в гиперссылки, которые можно развернуть.
• Автоматический поиск обновлений для утилиты.
• Секция Recently Used, показывающая машины, с которыми были последние соединения.
• Быстрый поиск ВМ по всем серверам.

Скачать VMware Boomerang 2.0 можно по этой ссылке (всего 12 МБ).

Как оказалось у нас на сайте нет инструкции по подключению локальных дисков сервера VMware ESXi в качестве RDM-дисков для виртуальных машин. Восполняем этот пробел. Как известно, если вы попытаетесь добавить локальный диск сервере ESXi в качестве RDM-тома для ВМ, вы там его не увидите:

Связано это с тем, что VMware не хочет заморачиваться с поддержкой дисков различных производителей, где будут размещены производственные виртуальные машины. Поэтому нам нужно создать маппинг-файл VMDK на локальное дисковое устройство, который уже как диск (pRDM или vRDM) подключить к виртуальной машине.

Для начала найдем имя устройства локального SATA-диска в списке устройств ESXi. Для этого перейдем в соответствующую директорию командой:

# cd /dev/disks

И просмотрим имеющиеся диски:

# ls -l

Нас интересуют те диски, что выделены красным, где вам необходимо найти свой и скопировать его имя, вроде t10.ATA___....__WD2DWCAVU0477582.

Далее переходим в папку с виртуальной машиной, которой мы хотим подцепить диск, например:

# cd /vmfs/volumes/datastore1/<vm name>

И создаем там маппинг VMDK-диск для создания RDM-тома, при этом можно выбрать один из режимов совместимости:

Для pRDM (Physical RDM):

# vmkfstools -z /vmfs/devices/disks/<имя t10.ATAитп> rdm_WD2DWCAVU0477582.vmdk

Для vRDM (Virtual RDM):

# vmkfstools -r /vmfs/devices/disks/<имя t10.ATAитп> rdm_WD2DWCAVU0477582.vmdk

После того, как vmdk mapping file создан, можно цеплять этот диск к виртуальной машине через Add Virtual Disk (лучше использовать для него отдельный SCSI Controller):

Второй способ, который работает не для всех дисков - это отключение фильтра на RDM-диски (это можно сделать и на сервере VMware vCenter). Для этого в vSphere Client для хоста ESXi нужно пойти сюда:

Configuration > Software > Advanced Settings > RdmFilter

Там и выставляется соответствующая галочка:

Однако, повторимся, этот метод (в отличие от первого) работает не всегда. Ну и учитывайте, что подобная конфигурация не поддерживается со стороны VMware, хотя и работает.

Мы уже писали о том, что такое и как работает технология VMware vStorage API for Array Integration (VAAI) (а также немного тут), которая позволяет передать операции по работе с хранилищами, которые выполняет компонент Data Mover в VMkernel, на сторону дискового массива. Это существенно улучшает показатели производительности различных операций (клонирования и развертывания ВМ, использования блокировок) за счет того, что они выполняются самим массивом, без задействования сервера VMware ESXi:

Если ваш массив не поддерживает примитивы VAAI, то чтобы склонировать виртуальный диск VMDK размером 64 ГБ, компонент Data Mover реализует эту операцию следующим образом:

• Разделяет диск 64 ГБ на малые порции размером в 32 МБ.
• Эту порцию 32 МБ Data Mover разделяет еще на маленькие операции ввода-вывода (I/O) размером в 64 КБ, которые идут в 32 параллельных потока одновремнно.
• Соответственно, чтобы передать 32 МБ, Data Mover выполняет 512 операций ввода вывода (I/Os) по 64 КБ.

Если же массив поддерживает примитив XCOPY (он же Hardware Offloaded Copy и SAN Data Copy Offloading), то для передачи тех же 32 МБ будут использованы I/O размером в 4 МБ, а таких I/O будет, соответственно, всего 8 штук - разница очевидна.

Интересно, как работает VAAI с точки зрения ошибок при передаче данных: например, мы делаем клонирование ВМ на массиве с поддержкой VAAI, и вдруг возникает какая-то ошибка. В этом случае VMkernel Data Mover подхватывает операцию клонирования с того места, где VAAI вызвал ошибку, и производит "доклонирование" виртуальной машины. Далее ESXi периодически будет пробовать снова использовать VAAI на случай, если это была кратковременная ошибка массива.

При этом проверки в разных версиях ESXi будут производиться по-разному:

• Для ESX/ESXi 4.1 проверка будет производиться каждые 512 ГБ передаваемых данных. Посмотреть этот параметр можно следующей командой:

# esxcfg-advcfg -g /DataMover/HardwareAcceleratedMoveFrequency
Value of HardwareAcceleratedMoveFrequency is 16384

Это значение частоты 16384 нужно умножить на порцию 32 МБ и мы получим 512 ГБ. Чтобы поменять эту частоту, можно использовать команду:

# esxcfg-advcfg -s <новое значение> /DataMover/HardwareAcceleratedMoveFrequency

• Для ESXi 5.0 и выше все проще - проверка производится каждые 5 минут.

Помимо описанных в нашей статье примитивов Full Copy, Zero Block и ATS, начиная с версии ESXi 5.0, поддерживаются еще 2 примитива:

• Thin Provisioning - механизм сообщения хостом ESXi дисковому массиву о том, что виртуальная машина или ее файлы с Thin LUN были удалены или перемещены (в силу разных причин - Storage vMotion, консолидация снапшотов и так далее), поэтому массив может забрать это дисковое пространство себе назад.
• Block Delete (UNMAP) - собственно, сам механизм забирания массивом назад дискового пространства через функции SCSI Unmap. Поддерживается с vSphere 5.0 Update 1, так как раньше с этим примитивом были проблемы. Более подробно об этом механизме можно прочитать в KB 2014849, а также в статье "VAAI Thin Provisioning Block Reclaim/UNMAP In Action".

С точки зрения дисковых массивов, работающих на NFS (прежде всего, NetApp) в ESXi 5.0 также появилась поддержка примитивов VAAI:

• Full File Clone – аналог функций Full Copy для VAAI на блочных хранилищах, предназначен для клонирования файлов виртуальных дисков VMDK.
• Native Snapshot Support – передача на сторону массива функций создания снапшота ВМ.
• Extended Statistics – включает возможность просмотра информации об использовании дискового пространства на NAS-хранилище, что полезно для Thin Provisioning.
• Reserve Space – включает возможность создания виртуальных дисков типа "thick" (фиксированного размера) на NAS-хранилищах (ранее поддерживались только Thin-диски).

Функции VAAI включены по умолчанию и будут использованы тогда, когда станут доступны (например, при обновлении Firmware дискового массива, которое поддерживает VAAI).

Мы уже много писали о продукте vGate R2 - средстве номер 1 для защиты виртуальной инфраструктуры VMware vSphere, которое полностью поддерживает пятую версию этой платформы, имеет сертификаты ФСТЭК и предназначено для безопасной настройки хост-серверов и ВМ средствами политик, а также защиты от НСД. В прошлых статьях мы рассказывали о защите облачных инфраструктур сервис-провайдеров от внутренних и внешних угроз. Сегодня мы постараемся обобщить угрозы, существующие в виртуальной среде, и предложить средства защиты на базе продукта vGate R2 и других решений от компании Код Безопасности.

Достаточно давно мы уже описывали средство централизованного администрирования хост-серверами VMware vSphere - vSphere Management Assistant (vMA). По сути, vMA - это вынесенная "сервисная консоль" за пределы хост-серверов ESXi в отдельный виртуальный модуль (Virtual Appliance), с которого удобно выполнять консольные команды RCLI (например, мониторинга - resxtop), а также хранить и запускать различные скрипты. Сегодня мы расскажем о том, как восстновить (сбросить) пароль на виртуальном модуле vMA.

Итак, загружаем VMware vMA 5, устанавливаем выбор на пункте меню "SUSE Linux Enterprise Server 11 SP1 for VMware" и нажимаем кнопку <e>:

В появившемся далее экране выбираем строчку с "kernel /vmlinuz" и снова нажимаем <e>:

В следующем экране, в строке ввода, вбиваем init=/bin/bash:

После нажатия <Enter>, вы вернетесь в педыдущее окно, где нужно нажать <b> для загрузки vMA. После загрузки вводим команду, которой и устанавливаем новый пароль:

# passwd vi-admin

Пароль установить непросто. Он должен соответствовать следующим политикам:

• Не менее 8 символовEight characters
• Хотя бы один символ в верхнем регистре
• Хотя бы один - в нижнем
• Хотя бы одна цифра
• Хотя бы один спецсимвол (#, $ и т.п.)

Понятно, что такой пароль никому не удобен. Поменять его можно командой:

# sudo passwd vi-admin

vMA будет жаловаться, однако пароль сменит:

С покупкой VMware компании Nicira стало больше разговоров о технологии VXLAN (Virtual eXtensible LAN), которая предоставляет расширенный механизм создания виртуальных сетей VLAN в крупных ИТ-инфраструктурах, объединяющих несколько датацентров компании (о ней мы уже упоминали). Разумеется, она нацелена на виртуализацию, и ее поддержка будет включена в платформу VMware vSphere в недалеком будущем. То есть VXLAN - это замена VLAN для создания прозрачной мобильной сетевой среды для виртуальных машин, имеющих возможность перемещаться между датацентрами.

Суть имеющейся сегодня проблемы заключается в том, что IP-адрес системы определяет две, по-сути разные, сущности: идентификатор системы и указатель на географическое размещение в сети (датацентр, сегмент), кроме того стандартная концепция VLAN позволяет использовать только до 4096 виртуальных сетей для логической изоляции классов систем, что в крупных инфраструктурах иногда оказывается недостаточно (особенно это касается IaaS-инфраструктур сервис-провайдеров, работающих с сотнями организаций, у каждой из которых свои VLAN).

Поэтому компании Cisco и VMware, к которым присоединились Citrix и Red Hat, разработали стандарт VXLAN, позволяющий организовать логические сети L2 поверх уровня L3 с возможностью минимального внесения изменений в существующую инфраструктуру сетевого взаимодействия в организациях. На данный момент черновик стандарта VXLAN в реализации IPv4 отправлен в организацию IETF, вскоре там будет и документ по реализации в IPv6.

Обзорный ролик по технологии VXLAN:

Образно говоря, технология VXLAN - это способ создания новых логических L2-сетей в рамках уже существующих L3-сетей. В одной VXLAN-сети виртуальная машина уникально идентифицируется двумя следующими параметрами:

• VXLAN Network Identifier (VNI) - 24-битный идентификатор виртуальной сети, а значит их всего может быть более 16 миллионов штук
• MAC-адрес машины

Соответственно, в одной VXLAN-сети не может быть машин с одинаковым MAC-адресом, но в разных VXLAN-сетях они вполне могут существовать (что актуально для виртуальных машин, MAC которых генерируется автоматически и глобально не уникален). Большое количество возможных VXLAN-сетей позволяет виртуальным машинам "путешествовать" между инфраструктурой организации и сторонними сервис-провайдерами без изменения сетевой идентификации, сохранением политик и изоляции внутри виртуальной сети безотносительно ее физического размещения (у себя или у IaaS-провайдера).

Для работы инфраструктуры VXLAN есть следующие компоненты:

• Необходима поддержка режимов Multicast, IGMP и PIM
• Идентификатор VNI внутри IP-пакета, только машины с одинаковым VNI могут взаимодействовать между собой
• Шлюз VXLAN Gateway
• Компонент VXLAN Tunnel End Point (VTEP) на стороне сервера виртуализации
• Виртуальная сеть VXLAN Segment/VXLAN Overlay

С точки зрения IP-пакета VXLAN, в сети IPv4 его размер увеличивается на 50 байт, а в сети IPv6 - на 70 байт. Работает это примерно так:

Допустим у нас есть виртуальная сеть VXLAN с VNI равным 864. Когда виртуальная машина VM1 хочет послать IP-пакет виртуальной машине VM2 происходят следующие вещи:

• VM1 по протоколу ARP посылает пакет с запросом MAC-адреса VM2
• Компонент VTEP1, размещенный на первом сервере VMware ESXi, инкапсулирует этот ARP-пакет в мультикаст-пакет, ассоциированный с виртуальной сетью с VNI 864
• Все остальные VTEP, получающие этот пакет, добавляют ассоциацию VTEP1 и VM1 в свои VXLAN-таблицы
• VTEP2  получает пакет, декапсулирует его и посылает броадкаст на портгруппы виртуальных коммутаторов, которым присвоен VXLAN c VNI 864
• VM2, находящаяся в одной из этих портгрупп, получает ARP-пакет и отвечает своим MAC-адресом
• VTEP2 на втором хосте ESXi формирует юникастовый пакет и отправляет его уже по существующему маршруту
• VTEP1 декапсулирует пакет и передает его виртуальной машине VM1

Теперь обратимся к структуре VXLAN-пакета:

В нем есть следующие заголовки (слева-направо):

Outer MAC Header (Ethernet Header)

Он содержит следующие поля:

• Destination Address - это MAC-адрес VTEP назначения, если этот VTEP является локальным по отношению к ближайшему роутеру, или MAC-адрес самого роутера, если VTEP находится за ним
• VLAN - опциональное поле с тэгом VLAN (не обязательно в VXLAN-реализации)
• Ethertype - тип пакета (для IPv4 установлен в 0×0800

Outer IP Header

• Protocol - содержит значение 0×11, чтобы обозначить, что это UDP-пакет
• Source IP - IP-адрес VTEP источника
• Destination IP - IP-адрес VTEP назначения

UDP Header

• Source Port - устанавливается передающим VTEP
• VXLAN Port - порт VXLAN IANA (еще не определен)
• UDP Checksum - контрольная сумма пакета на уровне VXLAN

VXLAN Header

• VXLAN Flags - различные флаги
• VNI - 24-битное поле с идентификатором VXLAN
• Reserved - набор зарезервированных полей

Итак, VM1 по описанному выше алгоритму узнала MAC-адрес VM2, после чего начинает ей адресно слать пакеты примерно так:

• VM1 посылает IP-пакет к VM2 с адреса 192.168.0.100 на адрес 192.168.0.101
• VTEP1 берет пакет и инкапсулирует его, добавляя следующие заголовки:
• VXLAN header с идентификатором VNI=864
• Стандартный UDP-заголовок с назначенным портом (VXLAN IANA)
• Стандартный IP-заголовок с IP-адресом VTEP назначения и признаком UDP-пакета
• Стандартный MAC-заголовок с MAC-адресом следующего устройства (next hop). В данном случае это роутер с маком 00:10:11:FE:D8:D2, который будет использовать стандартную маршрутизацию пакета по IP-сети до VTEP2.
• Далее VTEP2 получает такой пакет, распаковывает его (он узнает, что это VXLAN, так как это UDP-пакет) и вытаскивает VNI (864). Далее уже очищенный от обертки IP-пакет направляется к VM2, которая находится в портгруппе с VNI 864, перед чем VTEP убеждается, что она может получить пакет
• Виртуальная машина VM2 получает IP-пакет очищенным, как обычный IP-пакет

Таким образом, технология VXLAN, поддерживаемая в программном обеспечении платформы виртализации и роутеров позволит расширить сферу применения виртуальных сетей VXLAN в виртуальных облачных средах, где виртуальная машина сможет существовать в различных географически разделенных датацентрах, а пользователи смогут распределять нагрузку между своим частным облаком и облаком сервис-провайдера, не прибегая к переконфигурации виртуальных машин в рамках их виртуальных сетей.

Что еще можно почитать на эту тему (источники данной статьи):

• VXLAN Primer-Part 1
• VXLAN Primer-Part 2: Let’s Get Physical

Kenny сделал хорошую запись о списке дефолтных аккаунтов для различных продуктов VMware, а мы сведем это в таблицу для вашего удобства, добавив парочку отсутствующих продуктов:

Вроде всё. Если знаете еще что-то, напишите, пожалуйста, в каменты.

Мы уже писали про средства доверенной загрузки, которые нужно использовать в виртуальной инфраструктуре VMware vSphere 5, чтобы нейтрализовать угрозы, свзанные с доверенной загрузкой, и соответствовать требованиям руководящих документов ФСТЭК. Напомним, что когда дело касается виртуальных машин, организовать их доверенную загрузку можно с помощью сертифицированного средства защиты vGate R2 от компании Код Безопасности, в котором есть множество наборов политик, которые можно применять к различным объектам виртуальной инфраструктуры:

Однако надо помнить, что нужно защищать также и сами хост-серверы ESXi, находящиеся в датацентре компании. Для эффективной защиты сервера виртуализации, помимо vGate R2, необходим электронный замок - ПАК «Соболь» версии 3.0 для реализации следующих защитных механизмов:

• идентификация и аутентификация пользователей на входе в систему (непосредственно при запуске сервера);
• ведение журнала безопасности;
• сигнализация попыток нарушения защиты;
• запрет загрузки с внешних носителей;
• контроль конфигурации (PCI-устройств, ACPI, SMBIOS и оперативной памяти).

На эту тему компания Код Безопасности выпустила специальную брошюру "vGate R2 и ПАК «Соболь» - надежная защита виртуальной инфраструктуры на платформе VMware vSphere 5", где можно почитать об основных проблемах контроля целостности хост-серверов VMware ESXi и виртуальных машин и их доверенной загрузки:

Применение обоих средств защиты информации – ПАК «Соболь» версии 3.0 и vGate R2 – в комплексе позволяет защитить сервер с установленной платформой для виртуализации VMware vSphere 5 и нейтрализовать угрозы непосредственного доступа (угрозы, реализуемые до загрузки ОС, и угрозы, реализуемые после загрузки ОС).

Наличие у продуктов сертификатов ФСТЭК России позволяет использовать vGate R2 и ПАК «Соболь» версии 3.0 для защиты информации, составляющей коммерческую или государственную тайну в автоматизированных системах с классом защищенности до 1Б включительно.

Напомним, что версия vGate R2 с поддержкой vSphere 5 уже поступила в продажу, а бесплатную пробную версию продукта можно скачать тут.

Мы уже касались некоторых аспектов мониторинга производительности с помощью утилиты esxtop, которая есть на сервере VMware ESXi, а также метрик производительности хранилищ (и немного сетевого взаимодействия). Сегодня мы более детально взглянем на метрики производительности процессора (CPU) для контроля нагрузки виртуальных машин.

Если мы запустим утилиту esxtop, то увидим следующие столбцы (интересующее нас выделено красным):

Нас интересует 5 счетчиков, касающиеся процессоров виртуальных машин, с помощью которых мы сможем сделать выводы об их производительности. Рассмотрим их подробнее:

Счетчик %RUN

Этот счетчик отображает процент времени, в течение которого виртуальная машина исполнялась в системе. Когда этот счетчик для ВМ около нуля или принимает небольшие значение - то с производительностью процессора все в порядке (при большом его значении для idle). Однако бывает так, что он небольшой, а виртуальная машина тормозит. Это значит, что она заблокирована планировщиком ESXi или ей не выделяется процессорного времени в связи с острой нехваткой процессорных ресурсов на сервере ESXi. В этом случае надо смотреть на другие счетчики (%WAIT, %RDY и %CSTP).

Если значение данного счетчика равно <Число vCPU машины> x 100%, это значит, что в гостевой ОС виртуальной машины процессы загрузили все доступные процессорные ресурсы ее vCPU. То есть необходимо зайти внутрь ВМ и исследовать проблему.

Счетчики %WAIT и %VMWAIT

Счетчик %WAIT отображает процент времени, которое виртуальная машина ждала, пока ядро ESXi (VMkernel) выполняло какие-то операции, перед тем, как она смогла продолжить выполнение операций. Если значение этого счетчика значительно больше значений %RUN, %RDY и %CSTP, это значит, что виртуальная машина дожидается окончания какой-то операции в VMkernel, например, ввода-вывода с хранилищем. В этом случае значение счетчика %SYS, показывающего загрузку системных ресурсов хоста ESXi, будет значительно выше значения %RUN.

Когда вы видите высокое значение данного счетчика, это значит, что нужно посмотреть на производительность хранилища виртуальной машины, а также на остальные периферийные устройства виртуального "железа". Зачастую, примонтированный ISO-образ, которого больше нет на хранилище, вызывает высокое значение счетчика. Это же касается примонтированных USB-флешек и других устройств ВМ.

Не надо пугаться высокого значения %WAIT, так как оно включает в себя счетчик %IDLE, который отображает простой виртуальной машины. А вот значение счетчика %VMWAIT - уже более реальная метрика, так как не включает в себя %IDLE, но включает счетчик %SWPWT (виртуальная машина ждет, пока засвопированные таблицы будут прочитаны с диска; возможная причина - memory overcommitment). Таким образом, нужно обращать внимание на счетчик %VMWAIT. К тому же, счетчик %WAIT представляет собой сумму метрик различных сущностей процесса виртуальной машины:

Счетчик %RDY

Главный счетчик производительности процессора. Означает, что виртуальная машина (гостевая ОС) готова исполнять команды на процессоре (ready to run), но ожидает в очереди, пока процессоры сервера ESXi заняты другой задачей (например, другой ВМ). Является суммой значений %RDY для всех отдельных виртуальных процессоров ВМ (vCPU). Обращать внимание на него надо, когда он превышает пороговое значение 10%.

По сути, есть две причины, по которым данный счетчик может зашкаливать приведенное пороговое значение:

• сильная нагрузка на физические процессоры из-за большого количества виртуальных машин и нагрузок в них (здесь просто надо уменьшать нагрузку)
• большое количество vCPU у конкретной машины. Ведь виртуальные процессоры машин на VMware ESX работают так: если у виртуальной машины 4 vCPU, а на хосте всего 2 физических pCPU, то одна распараллеленная операция (средствами ОС) будет исполняться за в два раза дольший срок. Естественно, 4 и более vCPU для виртуальной машины может привести к существенным задержкам в гостевой ОС и высокому значению CPU Ready. Кроме того, в некоторых случаях нужен co-sheduling нескольких виртуальных vCPU (см. комментарии к статье), когда должны быть свободны столько же pCPU, это, соответственно, тоже вызывает задержки (с каждым vCPU ассоциирован pCPU). В этом случае необходимо смотреть значение счетчика %CSTP

Кроме того, значение счетчика %RDY может быть высоким при установленном значении CPU Limit в настройках виртуальной машины или пула ресурсов (в этом случае посмотрите счетчик %MLMTD, который при значении больше 0, скорее всего, говорит о достижении лимита). Также посмотрите вот этот документ VMware.

Счетчик %CSTP

Этот счетчик отображает процент времени, когда виртуальная машина готова исполнять команды, одна вынуждена ждать освобождения нескольких vCPU при использовании vSMP для одновременного исполнения операций. Например, когда на хосте ESXi много виртуальных машин с четырьмя vCPU, а на самом хосте всего 4 pCPU могут возникать такие ситуации с простоем виртуальных машин для ожидания освобождения процессоров. В этом случае надо либо перенести машины на другие хосты ESXi, либо уменьшить у них число vCPU.

В итоге мы получаем следующую формулу (она верна для одного из World ID одной виртуальной машины)

%WAIT + %RDY + %CSTP + %RUN = 100%

То есть, виртуальная машина либо простаивает и ждет сервер ESXi (%WAIT), либо готова исполнять команды, но процессор занят (%RDY), либо ожидает освобождения нескольких процессоров одновременно (%CSTP), либо, собственно, исполняется (%RUN).

На сайте компании Slym Software обнаружилась интересная утилита vSphere Configuration Backup, которая позволяет производить резервное копирование конфигурации серверов VMware ESXi из графического интерфейса:

Напомним, что резервную копию настроек ESXi можно сделать из командной строки. Сама же утилита vSphere Configuration Backup делает не только бэкап конфига ESXi, но и позволяет сделать резервную копию базы данных vCenter. По умолчанию политика хранения бэкапов (Retention Policy) составляет 2 недели.

Основные возможности утилиты:

• Автоматическое резервное копирование нескольких конфигураций серверов VMware ESXi 4 / 5
• Бэкап любых локальных БД Microsoft SQL сервера vCenter
• Управление политиками хранения и удаление устаревших резервных копий
• Резервное копирование одного сервера ESXi в один zip-архив
• В имени архива отражается номер билда каждого из ESXi
• Не требует установки (меньше 2 МБ)
• Шифрует пароли
• Простая настройка с консолью "Configuration Manager.exe"

Скачать бесплатную утилиту vSphere Configuration Backup можно по этой ссылке. Утилита очень простенькая, но для небольших компаний вполне подойдет.

Мы уже не раз писали о различных типах очередей ввода-вывода, присутствующих на различных уровнях в VMware vSphere, в частности, в статье "Глубина очереди (Queue Depth) и адаптивный алгоритм управления очередью в VMware vSphere". Недавно на блогах компании VMware появился хороший пост, упорядочивающий знания об очередях ввода-вывода на различных уровнях виртуальной инфраструктуры.

Если речь идет о виртуальных машинах на сервере VMware ESXi, работающих с дисковым массивом, можно выделить 5 видов очередей:

• GQLEN (Guest Queue) - этот вид очередей включает в себя различные очереди, существующие на уровне гостевой ОС. К нему можно отнести очереди конкретного приложения, очереди драйверов дисковых устройств в гостевой ОС и т.п.
• WQLEN (World Queue/ Per VM Queue) - это очередь, существующая для экземпляра виртуальной машины (с соответствующим World ID), которая ограничивает единовременное число операций ввода-вывода (IOs), передаваемое ей.
• AQLEN (Adapter Queue) - очередь, ограничивающая одновременное количество обрабатываемых на одном HBA-адаптере хоста ESXi команд ввода вывода.
• DQLEN (Device Queue / Per LUN Queue) - это очередь, ограничивающая максимальное количество операций ввода-вывода от хоста ESXi к одному LUN (Datastore).
• SQLEN (Storage Array Queue) - очередь порта дискового массива (Storage Processor, SP)

Эти очереди можно выстроить в иерархию, которая отражает, на каком уровне они вступают в действие:

Очереди GQLEN бывают разные и не относятся к стеку виртуализации VMware ESXi, поэтому мы рассматривать их не будем. Очереди SQLEN мы уже частично касались тут и тут. Если до SP дискового массива со стороны сервера ESX / ESXi используется один активный путь, то глубина очереди целевого порта массива (SQLEN) должна удовлетворять следующему соотношению:

SQLEN>= Q*L

где Q - это глубина очереди на HBA-адаптере, а L - число LUN, обслуживаемых SP системы хранения. Если у нас несколько активных путей к одному SP правую часть неравенства надо еще домножить на P - число путей.

Соответственно, в виртуальной инфраструктуре VMware vSphere у нас несколько хостов имеют доступ к одному LUN через его SP и получается следующее соотношение:

SQLEN>= ESX1 (Q*L*P) + ESX2 (Q*L*P)+ и т.д.

Теперь рассмотрим 3 оставшиеся типа очередей, которые имеют непосредственное отношение к хосту VMware ESXi:

Как мы видим из картинки - очереди на различных уровнях ограничивают число I/O, которые могут быть одновременно обработаны на различных сущностях:

• Длина очереди WQLEN по умолчанию ограничена значением 32, что не позволяет виртуальной машине выполнять более 32-х I/O одновременно.
• Длина очереди AQLEN - ограничена значением 1024, чтобы собирать в себя I/O от всех виртуальных машин хоста.
• Длина очереди DQLEN - ограничена значением 30 или 32, что не позволяет "выедать" одному хосту ESXi с одного хранилища (LUN) более 30-ти или 32-х операций ввода-вывода

Все эти очереди можно посмотреть с помощью esxtop:

Зачем вообще нужны очереди? Очень просто - очередь это естественный способ ограничить использование общего ресурса. То есть одна виртуальная машина не заполонит своими командами ввода-вывода весь HBA-адаптер, а один хост ESXi не съест всю производительность у одного Datastore (LUN), так как ограничен всего 32-мя I/O к нему.

Мы уже писали о функционале Storage I/O Control (SIOC), который позволяет регулировать последний тип очереди, а именно DQLEN, что позволяет корректно распределить нагрузку на СХД между сервисами в виртуальных машинах в соответствии с их параметрами shares (эта функциональность есть только в издании vSphere Enterprise Plus). Механизм Storage IO Control для хостов VMware ESX включается при превышении порога latency для тома VMFS, определяемого пользователем. Однако, стоит помнить, что механизм SIOC действует лишь в пределах максимально определенного значения очереди, то есть по умолчанию не может выйти за пределы 32 IO на LUN от одного хоста.

Для большинства случаев этого достаточно, однако иногда требуется изменить обозначенные выше длины очередей, чтобы удовлетворить требования задач в ВМ, которые генерируют большую нагрузку на подсистему ввода-вывода. Делается это следующими способами:

1. Настройка длины очереди WQLEN.

Значение по умолчанию - 32. Его задание описано в статье KB 1268. В Advanced Settings хоста ESXi нужно определить следующий параметр:

Disk.SchedNumReqOutstanding (DSNRO)

Он глобально определяет, сколько операций ввода-вывода (IOs) может максимально выдать одна виртуальная машина на LUN одновременно. В то же время, он задает это максимальное значение в IOs для всех виртуальных машин на этот LUN от хоста ESXi (это глобальная для него настройка). То есть, если задано значение 32, то все машины могут одновременно выжать 32 IOs, это подтверждается в случае, где 3 машины генерируют по 32 одновременных IO к одному LUN, а реально к LUN идут все те же 32, а не 3*32.

2. Настройка длины очереди AQLEN.

Как правило, этот параметр менять не требуется, потому что дефолтного значения 1024 хватает практически для всех ситуаций. Где его менять, я не знаю, поэтому если знаете вы - можете написать об этом в комментариях.

3. Настройка длины очереди DQLEN.

Настройка этого параметра описана в KB 1267 (мы тоже про это писали) - она зависит от модели и драйвера HBA-адаптера (в KB информация актуальна на июнь 2010 года). Она взаимосвязана с настройкой Disk.SchedNumReqOutstanding и, согласно рекомендациям VMware, должна быть эквивалентна ей. Если эти значения различаются, то когда несколько ВМ используют с хоста ESXi один LUN - актуальной длиной очереди считается минимальное из этих значений.

Для отслеживания текущих значений очередей можно использовать утилиту esxtop, как описано в KB 1027901.

Помните мы писали про баг VMware ESXi 5.0 Updare 1, где была проблема с неработающим авто-стартом виртуальных машин?

В конце прошлой недели были выпущены патчи для ESXi (Patch Release ESXi500-201207001), решающие эту проблему. Скачать их можно с портала патчей VMware, выбрав продукт ESXi версии 5.0.0 и дату - 12 июля:

Эти патчи включают в себя обновления подсистемы безопасности, а также множественные исправления ошибок, в том числе, фикс проблем Auto Start и SvMotion / VDS / HA :

Патчи описаны в KB 2019107.

Кроме этого, было также выпущено обновление сервера управления VMware vCenter Server 5.0 Update 1a:

Среди новых возможностей VMware vCenter:

• Поддержка следующих СУБД Oracle:
• Oracle 11g Enterprise Edition, Standard Edition, Standard ONE Edition Release 2 [11.2.0.3] - 64 bit
• Oracle 11g Enterprise Edition, Standard Edition, Standard ONE Edition Release 2 [11.2.0.3] - 32 bit
• Смена БД vCenter Server Appliance - встроенная база данных DB2 Express теперь заменена на VMware vPostgres
• Несколько исправлений ошибок - их можно найти в секции Resolved Issues

Скачать VMware vCenter Server 5.0 Update 1a можно по этой ссылке.

Процедура обновления:

1. Сделайте резервную копию БД vCenter
2. Деинсталлируйте vCenter hot-patch (если он есть)
3. Установите новую версию, указав существующую БД

Мы уже писали недавно об обновленном сборнике иконок, рисунков и диаграмм для документирования инфраструктуры VMware vSphere, который содержит в себе все необходимое для презентаций и документирования проектов по виртуализации. Напомним:

• VMW_PPT_LIBRARY_Icons-Diagrams_2Q12_2_of_3.pptx (2.6 MB)
• VMW_PPT_LIBRARY_Icons-Diagrams_2Q12_3_of_3.pptx (2.9 MB)
• VMW_PPT_LIBRARY_Icons-Diagrams_2Q12_1_of_3.pptx (17.4 MB)

Недавно один добрый человек перевел это все в формат Microsoft Visio:

• Part 1
• Part 2

Еще один выложил полезные иконки, которых мало, но они могут пригодиться:

И он же сделал интересный плагин для Wordpress, показывающий параметры виртуальной инфраструктуры в блоге. Может тоже кому пригодится:

Что-нибудь еще полезное по этой теме подскажете?